NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/12544

Internet Message Format | 1996-08-05 | 4.6 KB

Path: imonics.com!not-for-mail
From: [e-mail] (Imonics Corporation)
Newsgroups: comp.lang.c++,comp.lang.c,comp.object,comp.software-eng
Subject: Re: Portability of code & skills (Beware of "C" Hackers etc)
Date: 20 Mar 1996 09:46:46 -0500
Organization: Imonics Corporation
Message-ID: <4ip5om$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: bughouse.imonics.com

In article <[e-mail]>, Larry Baker  <[e-mail]> wrote:
>UNIX was never free.  AT&T charged something like $50,000 (don't
>quote me) for a full UNIX source license to corporations in the
>70's and early 80's, though they may have given it away to
>Universities.

AT&T was forbidden to sell the software until phone co.
deregulation.  It was "free" (you paid for your own tape) if you
were an educational institution.  That was the only way anyone
could get it.  It was not for sale.

>From my point of view UNIX was and is a success for simple
>economic reasons.  For a few 100k$ a computer maker could
>license an operating system to port to a new computer, and
>voila! new computer out the door.  Having UNIX on your (new)
>computer made it easy for 3rd-party software vendors to
>port products to your machine, making it marketable to a
>wide audience.

I think Unix and C are a success because they are deliberately
obscure.  All those "computer science" graduates just love
knowing a secret code with which they can amaze people.  They
don't WANT it to be easy to understand; that would mean that
other people could and would read their code and be able to do
the things they do.  That would weaken their club membership
(sort of like letting in girls is to 7-year-olds).

>Remember that before UNIX, there was no commercially available,
>portable, licenseable multi-user OS that could live on vastly
>different computer architectures. (ok, I'm ignoring OS/9, but
>I think it's more of a real-time, niche-oriented OS.)
>
>The same argument holds for the "success" of C.  At the time,
>the only other language that "competed" with C for the mainstream,
>popular (PC, workstation) programming population was Pascal,
>compiled BASIC, FORTRAN or PL/M.  FORTRAN was the only one
>with a recognizable, widely accepted standard and reasonable
>portability.

The portability issue is/was partially myth; it gave rise to
non-computer people (and some who should have known better) saying
things like "Write it in C so it will be portable".  That's
horse manure.  It is easier to WRITE portable code in C because
there are more C compilers, but that doesn't mean that C code
is inherently more portable.  The other thing about portability
is the commercial part of the myth -- companies don't really
want to change machines and operating systems every few years,
that's for people who regard them as toys.

>
>C was (and is) reasonably portable, relatively simple, (especially
>the simple K&R based compilers), cheap to implement, and low-level
>enough to appeal to the people having to squeeze the last cycle
>of performance out of early PCs and Workstations.
>
>Low-level performance is not as much of a mainstream priority
>today, but it was in the 70's and 80's.  Ever programmed on
...
>
>Don't be too hard on the so-called "C-hackers" who tried to
>squeeze every bit of memory, every cycle of performance out
>of some of these older machines.  There was a time when their
>skills were needed.  They're simply practicing a skill that
>isn't all that necessary today.

This SAME ARGUMENT (that it isn't necessary today, but was "back
when) has been made for AT LEAST 10 years, and perhaps 15.  The
problem is not that people need to squeeze performance out of
slow machines -- they have to do that sometimes, but that isn't
the problem.  The problem is that they use that argument to justify
poor engineering practice even when performance is not an issue.
Witness the people who will do micro-second-saving-practices when
writing a user interface, where the next thing to happen is waiting
for keystrokes.  Witness people who will argue against splitting
things into subroutines "because of performance" without a single
minute spent evaluating whether there are any performance problems
to be solved.

If I find a person who will engineer a piece of software, measure the
performance, and then examine which pieces require optimization in
order to speed up the system; if this person will document what he
is doing so that those who come later can figure it out, then he can
put as many gotos, obscure pointer arithmetic, and etc. into his code
as will get the job done.  I won't object, and I won't call it hacking.

rc